一个好的持续交付流水线是怎样的?

张燎原、张裕阿里云云栖号 2022-07-13

作者 | 张燎原、张裕

文章来源 | 阿里巴巴云效团队

上一讲我们讲了持续部署的4个目标：准确可预期的部署结果、部署过程不影响线上服务、有可持续部署的软件增量、低成本和高效地部署发布，并分析了如何做到。

可是，有了好的持续部署实践，如何才能规模化落地呢？

承载实践最好的方式就是工具。持续部署过程的最好载体就是流水线，因为持续部署本身就是一个逐级递进的流水线。

持续发布流水线

如上图所示，我们可以看到，从最早拉取代码、构建、验证、部署，整个过程是一个逐级递进的过程。如果代码发生变化，或配置发生变化，或代码依赖发生变化，流水线将会被重新触发。从拉取代码开始，直至流程执行完成或中断。我们会按照构建的配置来构建制品，将制品保存到制品仓库，产生构建产物，接下来我们会基于构建产物做验证，验证通过就可以进入部署，部署成功就意味着这个特性已经被成功发到了线上的运行环境中。

在图中我们增加了几个部分，包括研发管理平台、配置中心、监控中心、运维发布平台。

在最简化的流水线里面我们看不到这些，但是在大家的实际工作当中会存在这几个概念：

我们在执行流水线的时候，会跟研发管理平台做交互，比如是否有统一的构建规则；在整个公司的层面或者是部门的层面是否有统一的约束，比如代码的检测标准，可能是公司统一的，这些都会在研发管理平台维护。

配置中心是管理服务的特性开关和动态配置等，配置中心的配置是需要下发给运行中的服务的。

流水线的发布过程和监控中心打通，监控数据的变化，反过来会影响发布，所以整个流水线和监控需要做集成。这个集成可以通过人，但是更好的方式是通过工具链。

部署策略一般沉淀在运维同学的脑子里，或者是运维平台的工具里，这些策略要被应用到流水线上，部署过程当中流水线和运维发布平台有非常强的耦合。

另一个很重要的点，我们在运维平台上有很多安全策略和敏感信息，这些是不可以，或者是不能承载在流水线或者代码中的，需要通过运维发布平台做管控。

这样，我们通过流水线跟我们现有的研发系统就形成了有机的整合，以达到高效发布的目的。

一个好的流水线是怎样的？

既然流水线是如此重要的载体，一个好的流水线应该是什么样的呢？

首先，流水线应该是可描述的，流水线可以像一幅画或者一项工作那样被具象化出来。特别重要的是流水线可以具象化表达研发模式，通过流水线保证发布流程的一致性。基于流水线可以把实践快速复制，如应用同一条流水线的模板就可以应用同一个实践。

第二，流水线应该是可观测的。整个发布过程发到哪、发了什么、中间有什么问题、成功还是失败，是可观测的，并且这个观测是和监控打通的，这样就可以保证发布过程有保障。

第三，整个过程是自动化的。比如构建完不需要到验证阶段再手动触发，整个过程是自动流转的。流程应该建立在工具的基础上，不依赖人，这就是自动化。

以从右到左、面向终态的思维来看，我们的终态是有一个稳定可预期的系统，为此需要找到一个稳定可预期的软件的制品版本，达到一致性的环境，再去进行部署。

部署的时候要符合上一讲所说的4个原则。无论是持续集成、持续测试，无非是要获取确定的软件制品，然后按照4个原则部署上去，所有的这些能力和活动都是为了最终的目标来服务的。

流水线应用举例

我们结合例子来看一下确定持续交付流水线的整个过程。

首先是模板。我们会在团队或者是公司层面有一些最佳实践的模板，比如说有JAVA后端应用的流水线模板，流程上从代码扫描开始，执行测试，然后是构建和部署。有了这个模板之后，可以在团队内所有JAVA后端应用间复用。

第二是团队统一管控和能力复用，比如统一定义某些环境变量，在运行中注入Secret或者账号信息，这些不希望在代码中明文存储，但是我们会通过工具注入下去。假设把devops.test.local作为我们自己的研发管理平台，我们可以通过类似上图的方式与之集成，我们也可以在平台里定义敏感信息，或者维护公共变量，然后在每一个流水线的步骤里面引用，达到全局复用的效果。

其次，流水线是具备观测性的。我们可以知道当下流水线的情况，最新的一次运行是否完成、有没有连续失败的情况等。从流水线视角可以看到一个feature从开发、集成到发布的整个阶段是什么样的，中间是否存在问题。比如图中的流水线从开发完到集成之间有很长时间的等待，这里可能存在阻塞，可以下钻进行进一步分析。

下面是我们基于云效做的DevOps方案大图。云效包含完整的DevOps研发工具链。以需求的角度，在任务看板里面拿到相应的开发任务就可以开始开发，提交代码，然后在代码层面做检测和安全扫描，接着执行构建，集成，验证，最后上线。

右上角的“1-1-1”是我们的愿景：我们希望做到1个小时的发布前置时长，从代码提交到发布到生产1个小时完成，我们希望每天至少有1个可发布的版本，我们希望每一个应用每周至少发布1次。

“1-1-1”能够帮助我们去发现在整个集成发布过程当中存在的问题：为什么不能做到1小时的发布前置时长？由哪些原因导致的？这时就需要找到问题的关键所在，其实是给自己设定一个目标，然后再看现状。现状跟目标之间有一段距离，这个距离就是需要解决的问题。

有了基于云效的Codeup、Flow，也可以构建其他的交付模式，比如说移动APP的持续交付模式。

另一个是Web应用，常见的云的服务端的发布。

或者是前端，直接把相应的前端构建物发送到CDN，这些都是比较常见的发布流程。